[00:28.680 --> 00:36.800]  All right. We are here with our next QA session with Jiska and Francesco for the Spectra wireless,
[00:36.800 --> 00:43.280]  new wireless escalation targets talk. Do you guys want to give yourself a little bit of an intro?
[00:43.980 --> 00:45.520]  Jiska, do you want to start?
[00:48.200 --> 00:54.520]  Yeah, okay, then I'll start. I'm a postdoc at TU Darmstadt in Germany at the Secure Mobile
[00:54.520 --> 01:00.500]  Networking Lab, and I've been, yeah, recently working a lot with Bluetooth. Before, I've been
[01:00.500 --> 01:07.260]  working also a bit on Wi-Fi and IoT devices and all sorts of wireless communication.
[01:10.440 --> 01:16.780]  Hi, I'm Francesco Gringoli. I'm an assistant professor at the University of Brescia and
[01:16.780 --> 01:21.540]  have been playing with wireless technologies in the last 15 years.
[01:21.540 --> 01:29.480]  That's great. Thank you both. So, I mean, I'm going to start off with some a little bit simpler
[01:29.480 --> 01:35.920]  questions. So, you talked a lot about this new vulnerability that's between the two cores.
[01:35.920 --> 01:41.860]  Is this something that can be patched? It's hard to say. So, there are parts that
[01:41.860 --> 01:48.620]  definitely are not patchable because they are for the performance improvements. So,
[01:48.620 --> 01:55.200]  the stuff that goes, like, between the U-code that Francesco modified and the communication
[01:55.200 --> 02:00.020]  with the serial interface on the Bluetooth side, this is something that you need, at least if you
[02:00.020 --> 02:05.220]  don't want to lose performance. And this is also all in hardware, I guess. So, this is something,
[02:05.220 --> 02:12.900]  like, in a future chip, it might be changed in a way that you can infer less information,
[02:12.900 --> 02:17.560]  but it's probably not patchable in that sense or not easily patchable.
[02:17.560 --> 02:22.940]  The shared RAM is something that they should remove, but I didn't see them remove it yet.
[02:22.940 --> 02:28.100]  And I don't know if they can actually unmap it in the generation of chips or if this also needs
[02:28.240 --> 02:32.820]  a new generation of chips. I didn't see the shared RAM actually being used anywhere. So,
[02:32.820 --> 02:39.640]  that's the weird thing, right? The shared RAM exists. Yeah. So, it exists, but it's really
[02:39.640 --> 02:47.600]  not being used for anything or at least for nothing that I could see. So, this is the thing
[02:47.600 --> 02:50.580]  that they should remove, because it's the most dangerous part.
[02:51.660 --> 02:55.620]  So, we got a question from Cooper Q, and this was actually something that I was interested in
[02:55.620 --> 03:00.780]  as well. You mentioned LTE is on some of the same frequencies, and I know that there are some
[03:00.780 --> 03:06.640]  all-in-one chips that include LTE in addition to their Bluetooth and wireless stacks. Have you
[03:06.640 --> 03:14.190]  tried going through the LTE baseband or use the Bluetooth interface to get at the LTE radio?
[03:15.100 --> 03:21.880]  Not yet. So, what we tried is we tried to see if this connection exists at all. And I can tell that
[03:21.880 --> 03:28.080]  in the Cypress Bluetooth symbols, there's definitely symbols that are called LTE or MWS
[03:28.080 --> 03:36.820]  something. And then I also took some logs on an iPhone and like iPhone 7 and newer. And on those
[03:36.820 --> 03:41.880]  devices, what you can see is that there are HCI commands. So, that's from the operating system
[03:41.880 --> 03:49.200]  Bluetooth daemon to the chip that include MWS, which is the configuration for the LTE coexistence.
[03:49.200 --> 03:54.520]  So, they are definitely using it. I just didn't try to exploit it yet.
[03:55.800 --> 04:02.560]  Cool. Fair enough. This one, this one's one I'm going to, I'm going to have to read verbatim
[04:02.560 --> 04:06.240]  because it's a little out of context. I don't know what it was. In the talk, you mentioned
[04:06.240 --> 04:08.680]  Frankenstein. Can you talk a little bit about it?
[04:10.880 --> 04:18.700]  Yeah. So, that's another paper. So, actually, the main work of this is from Jan, who is not here,
[04:18.700 --> 04:26.020]  but that's one of my former students. And he made some snapshotting for Bluetooth chips
[04:26.020 --> 04:31.240]  of Broadcom and then also emulation. And the interesting part about this emulation is that
[04:31.240 --> 04:37.300]  it includes thread switches and a virtual modem so that you can attach it to your Linux host and
[04:37.300 --> 04:42.440]  you actually can start scanning for devices and get back random devices. So, you have like a full
[04:42.440 --> 04:50.000]  stack emulation in that sense. And this is something that we are going to present next week
[04:50.000 --> 04:59.420]  at USENIX security. The paper is already public. And also, the software is on GitHub since a while.
[04:59.620 --> 05:07.380]  Cool. Could you send me links for that information? You can do it after the Q&A. I just want to be
[05:07.380 --> 05:11.700]  able to drop it in track one for anyone that's interested in following up with that information.
[05:12.440 --> 05:16.880]  So, anyone that's paying attention, if you want the extra information, the links to the
[05:17.540 --> 05:23.880]  paper and everything else will be in the track one room as soon as this is over.
[05:25.420 --> 05:34.180]  Okay, on to the next question. So, regarding the CVE-2019-15063 denial of service Bluetooth
[05:34.180 --> 05:40.040]  Wi-Fi exploit, was that the specific one that you guys were working on? I don't remember CVE numbers
[05:40.040 --> 05:45.300]  off the top of my head. Anyways, the question is, how are you manipulating the register that
[05:45.300 --> 05:49.180]  results in crashes? Are you physically accessing the chipset? Or can this be done remotely?
[05:50.200 --> 05:55.140]  Ah, so yeah, that's, so it's kind of two stages, right? So, you first need some remote code
[05:55.140 --> 05:59.540]  execution, either on Wi-Fi or on Bluetooth. And then you could write to the register.
[05:59.760 --> 06:07.640]  And what we do for debugging is actually, so for Bluetooth, when we modify Bluetooth,
[06:07.640 --> 06:13.020]  then we have internal blue, which is a framework that supports the vendor specific commands from
[06:13.020 --> 06:19.140]  Broadcom to manipulate the Bluetooth part. And for Wi-Fi, there's another thing next month,
[06:19.140 --> 06:25.820]  I think Francesco can tell a bit more about next month. Yeah, it's a project that allows people to
[06:25.820 --> 06:35.460]  do binary patching of the wireless driver, so that you can modify and then add functionalities.
[06:35.460 --> 06:39.760]  But of course, this is not the remote execution, it's just for modifying the binary image
[06:39.760 --> 06:45.280]  without having access to the source code, which is a proprietary. And this allows to modify both the
[06:45.280 --> 06:52.720]  ARM, the ARM core, and also the U-code part that is the lowest part accessible in the hardware.
[06:53.080 --> 06:57.340]  That's really cool. Is that a tool that is going to get released like
[06:58.120 --> 07:04.420]  upcoming? Is that part of the Usenix talk? No, next one is, I just pasted it also in our
[07:04.420 --> 07:09.840]  private chat, so you can copy it later. Next one is something, since when is it public? I don't
[07:09.840 --> 07:18.520]  know, 2016, 17? Yeah. And the interesting part about next month is so next month was just built
[07:18.520 --> 07:25.260]  to actually modify the Wi-Fi firmware without the intention to really hack it. So like,
[07:25.260 --> 07:31.080]  more for sending arbitrary signals, turning your smartphone into an SDR. And the interesting part
[07:31.080 --> 07:37.060]  here is that back then in 2017, actually, Google Project Zero and Itay Eisenstein used this
[07:37.060 --> 07:42.800]  knowledge to dig a bit further into the Broadcom chips. So like Broadcom and stuff like this was
[07:42.800 --> 07:50.080]  also not only but also based on next month, and also later work, they always use next month.
[07:50.200 --> 08:01.060]  So that's a very interesting thing about this. And then for the Bluetooth stuff, we said like,
[08:01.580 --> 08:08.900]  well, how do you guys go about researching phones, since for the most part, everything
[08:08.900 --> 08:13.080]  seems to be closed source? They're asking to talk about like the research process,
[08:13.080 --> 08:16.060]  like if you were going to try and exploit a new phone?
[08:17.640 --> 08:26.060]  Ah, yeah, so that's, that's the thing. So the first part is, I mean, if you don't have,
[08:26.060 --> 08:30.480]  already have a working over the air exploit, which is hard to get, especially if you don't
[08:30.480 --> 08:35.440]  have the ROM of a device and so on, even if you had an exploit, like getting it working on a new
[08:35.440 --> 08:44.580]  device would be hard. So usually we start with a rooted smartphone, or a jailbreak. Or, I mean,
[08:44.580 --> 08:51.840]  also MacBooks have Broadcom chips. So and there you are already root. So it depends a bit. And
[08:51.840 --> 08:57.100]  then we would dump the ROM. And the ROM, I mean, for Wi Fi and for Bluetooth, it's pretty much the
[08:57.100 --> 09:02.520]  same. And for Wi Fi, the ROM also contains the U code. And the U code is the thing that runs in
[09:02.520 --> 09:08.420]  the D11 core. So what Francesco modifies, and for me, it's more the Bluetooth firmware.
[09:09.820 --> 09:14.220]  And then it's very annoying, because like the stuff is still without any symbols. And
[09:14.220 --> 09:18.540]  especially Bluetooth also doesn't have any debug strings, the U code doesn't have any
[09:18.540 --> 09:24.940]  debug strings, the Wi Fi firmware has a few debug strings. And since this is like,
[09:24.940 --> 09:29.440]  so even the memory layout is somewhat unknown, and you need to get it and so on. And because of
[09:29.440 --> 09:38.020]  this really horribly loads into IDA. So it really looks ugly. Yeah, fair. And I think Francesco,
[09:38.020 --> 09:43.760]  for you, it's even the case that you get new instructions, right? Yes, for the U code,
[09:43.760 --> 09:52.280]  there is no actually corresponds between the U code and the any known CPU. So we had to do this
[09:52.280 --> 09:58.180]  reverse engineering for understanding the meaning of these instruction set, and then adding
[09:58.180 --> 10:04.640]  instructions, because Broadcom, during the years, added new instructions. And yeah, the reason this
[10:04.640 --> 10:10.480]  was very difficult, because it's not ARM that you compile or disassemble, but you have to develop
[10:10.480 --> 10:19.760]  your own tool chain for this. So what helped is that Broadcom didn't change much the platform,
[10:19.760 --> 10:26.640]  since they introduced it 15 years ago. So they are additionally adding instructions. And
[10:26.640 --> 10:31.560]  also what helps is that the U code is very short is less than 64 kilobytes.
[10:33.640 --> 10:39.780]  Have you either of you looked into any of the newer, like mesh Bluetooth protocols?
[10:40.900 --> 10:46.140]  Bluetooth mesh. So a colleague of mine did that Lars, and he looked into the friendship together
[10:46.140 --> 10:52.100]  with a few other people in our team. So it's so yeah, we did it in our team. But the mesh is not
[10:52.100 --> 10:56.880]  really interesting. I mean, it's just using Bluetooth LE advertisements. So from a, at least
[10:56.880 --> 11:03.460]  from a lower level perspective, it's nothing special. I mean, of course, implementations on
[11:03.460 --> 11:11.200]  top are interesting then. But I mean, I do a lot of lower layer stuff. He just showed that the
[11:11.200 --> 11:18.620]  encryption and so on in the, in the friendship of groups is broken, and Bluetooth SICK send funny
[11:18.620 --> 11:28.980]  responses. Of course it is. Someone else is shouting out that a lot of your and related
[11:28.980 --> 11:35.960]  work on BLE is also available as pre prints from YSEC 2020. And they also threw through a link in
[11:35.960 --> 11:40.500]  there. I just wanted to shout that out. Francesco also has done stuff with Bluetooth sniffing,
[11:40.500 --> 11:46.140]  right? You've built a Bluetooth sniffer. Yeah, this real time sniffer using a software defined
[11:46.140 --> 11:51.920]  radio for capturing all the channels at the same time and GPU for decoding and brute forcing
[11:52.700 --> 11:57.040]  lowest address part address and low energy session ID.
[11:57.040 --> 12:02.320]  Yeah, I know that there's a lot of like kind of a wide range of like capabilities of SDR stuff. Is
[12:02.320 --> 12:07.540]  there like a minimum requirements for the SDR hardware to do that level of sniffing and
[12:09.240 --> 12:11.120]  for Bluetooth?
[12:13.060 --> 12:21.500]  Well, if you have SDR that can sniff 80 megahertz is better. But for sniffing Bluetooth classic,
[12:21.500 --> 12:28.580]  we demonstrated that it's enough to capture only 16 channels out of 80. Then you can also use one
[12:28.580 --> 12:37.260]  of these cheap SDR like, like Hacker F or Blader F. So you do not need to buy a very expensive
[12:38.080 --> 12:42.840]  1000 euro 80 megahertz, but you can buy one of these for 100 bucks.
[12:43.840 --> 12:44.800]  That's awesome.
[12:44.800 --> 12:45.700]  It should work.
[12:45.700 --> 12:48.340]  Yeah, accessible hacking. It's nice.
[12:49.380 --> 12:54.600]  Got one person asking, do you think Broadcom is relying a little bit too much on security
[12:54.600 --> 12:56.560]  through obscurity with some of these chips?
[12:58.500 --> 13:02.480]  I mean, so what you can actually see, and that's an interesting development. So
[13:02.480 --> 13:09.440]  on the first bug that Jan discovered with Frankenstein is one in the enhancing viral
[13:09.440 --> 13:15.900]  response. And when he submitted that one, they said, we already know the bug, and we just didn't
[13:15.900 --> 13:21.800]  find it anywhere. And then I got like the newest Samsung Galaxy S10e and extracted the ROM. And
[13:21.800 --> 13:28.460]  this one actually had a patch and it had a compile date of April 2018. And that also means like they
[13:28.460 --> 13:33.600]  cannot change the ROM, so they cannot tell us lies about the ROM. And we reported it afterwards.
[13:33.600 --> 13:40.480]  So that actually means they knew it before. But, and now that's the interesting part of the story.
[13:41.140 --> 13:45.420]  They didn't patch it backwards in the older devices because it was not publicly known as
[13:45.520 --> 13:52.340]  a bug and you could easily unroll the patches. Now, the thing is, they definitely increased
[13:52.340 --> 14:01.180]  the security, I would say, after the bugs in 2017 were public. So, I mean, it took them a year
[14:01.180 --> 14:06.540]  probably to do some pen testing and so on. But you can see like 2017, the first public incidents
[14:06.540 --> 14:14.160]  happened. 2018, the first kind of secret patches make it into the firmware. And also they started
[14:14.160 --> 14:20.420]  using like, I don't know, stuff like secondaries. They didn't have it before. So this is things that
[14:20.420 --> 14:25.180]  now are going into the firmware. It's still not like super perfect and everything. It's still,
[14:25.180 --> 14:31.340]  of course, closed source. But I mean, most firmware in wireless chips is closed source.
[14:31.340 --> 14:37.740]  Yeah. So at least they are trying to work on it. And I think they are there on that,
[14:37.740 --> 14:40.700]  like security by obscurity doesn't really work.
[14:41.240 --> 14:50.280]  Fair enough. So someone is asking where people could find the source code for that Bluetooth
[14:50.280 --> 14:58.590]  sniffer. Francesco, I think that's it. Yeah, I can send you. Yeah, I can send you a link.
[14:58.590 --> 15:01.690]  If you send me a link, I will post that with everything else.
[15:02.530 --> 15:10.910]  Yeah. And another one. Do you think a Bluetooth or Wi-Fi based worm is feasible in the wild or
[15:10.910 --> 15:14.690]  interoperability between implementations too difficult to bridge?
[15:15.030 --> 15:20.410]  So I think for Wi-Fi, it's hard because for most stuff, you need to actually join an access point
[15:20.410 --> 15:25.590]  or something like this. But for Bluetooth, you have this master slave mode. So you can actually
[15:25.590 --> 15:30.090]  have a device like a smartphone is usually capable of being master and slave. Some like
[15:30.090 --> 15:34.750]  cheap devices, cheap IoT devices sometimes are only in slave mode and cannot do master.
[15:34.750 --> 15:39.710]  But if you can be slave and master, then you can be part of this, let's say,
[15:39.710 --> 15:48.710]  network and distribute the malware. And I think there is, let's say, a sufficient fraction of
[15:48.710 --> 15:54.950]  popular devices. So it depends if it's in the operating system, then it would have to be like
[15:54.950 --> 16:00.470]  compatible iPhones or something. And I mean, if you just there's not much diversity in iPhones.
[16:00.470 --> 16:05.650]  So if you just take like the top selling iPhones or something that also would work on the chip
[16:05.650 --> 16:11.490]  base. On Android, you have more diversity. But still, if you would say you just pick the top
[16:11.490 --> 16:20.010]  Samsung and Galaxy, and maybe the pixels or something. Yeah, that could work. So Jan actually
[16:20.010 --> 16:27.670]  uncovered vulnerability in the Android Bluetooth daemon. And that one would have been vulnerable.
[16:27.670 --> 16:35.630]  And it was fixed in February. I mean, still, yeah. So you couldn't infect like 100% of devices.
[16:36.020 --> 16:41.710]  Considering that you have your Bluetooth on and walk around and so on, that would be a threat.
[16:41.930 --> 16:47.570]  So the reason why I think people wouldn't build it is how do you control it? Because then you need
[16:47.570 --> 16:52.610]  to have some communication over the internet or something like how do you do like a command and
[16:52.610 --> 17:00.270]  control server for Bluetooth form in a way that is like stealthy and really, I don't know. So I
[17:00.270 --> 17:07.030]  think it's really more the bigger threat is definitely taking over nearby devices or like
[17:07.030 --> 17:12.410]  hacking someone or like going next to an office train station somewhere where you know, like
[17:12.410 --> 17:17.310]  interesting people are and taking over their devices. But I think even if it's vulnerable,
[17:17.310 --> 17:23.910]  I think this is nothing that people would build. But I mean, maybe someone builds it someday.
[17:23.910 --> 17:29.770]  So I won't build it because, well, I wouldn't. But I mean, maybe someone is crazy enough to do
[17:29.770 --> 17:34.590]  this, right? It's just true. I mean, you could potentially just do it without a financial
[17:34.590 --> 17:41.970]  motivation, just to see if it works or something. Yeah. So switching gears just a little bit.
[17:42.570 --> 17:46.530]  Did you guys report this to vendors? Like how was how did that communication like turn out?
[17:46.530 --> 17:55.670]  Was it positive? Was it negative? Was it? Tell me. Yeah, so the very first report about this
[17:55.670 --> 18:01.290]  denial-of-service was in August last year. So that's like a year ago. And I think they didn't
[18:01.290 --> 18:05.410]  really take it serious because it was just denial-of-service, right? And even if you have
[18:05.410 --> 18:09.970]  denial-of-service with an operating system reboot, it's like nothing that you could really control,
[18:09.970 --> 18:14.490]  right? So like writing FF to one register, it reboots. Okay. But who cares? Because you need
[18:14.490 --> 18:22.250]  RCE first. It's just it's hard to control. And interestingly, in September that year,
[18:22.250 --> 18:29.310]  the iOS 13 update came out, and it actually mentioned Jan, Francesco, and me. So and so
[18:29.310 --> 18:33.030]  Jan was working mainly on Frankenstein. I also worked a bit on Frankenstein. And
[18:33.870 --> 18:38.170]  the coexistence was what I did with Francesco. So I was like, okay, if they also mentioned
[18:38.170 --> 18:42.990]  Francesco and me, they should have fixed it. But they didn't. So I was a bit confused that
[18:42.990 --> 18:47.490]  all the names were mentioned there in the iOS 13 update. And also a month is a bit too short.
[18:47.490 --> 18:52.330]  And everything that they patched but silently already before was the enhanced inquiry response
[18:52.330 --> 18:58.170]  issue. And then like I poked them from time to time, did you already patch it? Why didn't you
[18:58.170 --> 19:08.190]  patch it? And so on. And at 3063 on stage, I also showed that this is still unpatched and so on.
[19:10.030 --> 19:15.170]  And they still didn't patch it. And back then I already had in mind. So that was when I already
[19:15.170 --> 19:20.210]  called Francesco and said, like, in January, we are going to build speculative transmission.
[19:20.250 --> 19:24.490]  So that was, I was like, please get things in that direction of a text
[19:25.130 --> 19:29.750]  fixed. But yeah, and then end of January, I actually knew that this is probably unpatchable.
[19:29.750 --> 19:34.990]  And that was when I sent Apple that email, you know, why Broadcom didn't send you a fix because
[19:34.990 --> 19:44.610]  it's unpatchable. What are you telling us? And yeah, so at least so that that means like Broadcom
[19:44.610 --> 19:50.130]  and also like some of their customers got like some, some notice already in January, about those
[19:50.130 --> 19:55.570]  things like that they are broken. And I mean, also like the ones before just about denial of service.
[19:55.690 --> 20:00.650]  And then I was building a few more pox beginning of March, because I was very busy in between.
[20:00.650 --> 20:05.190]  But that were like the final proof of concepts like that there's even this ram sharing and it
[20:05.190 --> 20:10.030]  is exploitable and stuff like this, which I mean, Broadcom should have known it already.
[20:10.030 --> 20:15.190]  And they already introduced this, this one patch that you no longer can write
[20:15.710 --> 20:20.030]  to the Bluetooth ram after drive initialization that one was already pushed to devices
[20:20.030 --> 20:26.110]  somewhere around March. So this is like the thing that they did against it and that they could
[20:26.110 --> 20:32.810]  easily do because they were like informed quite a long time before. And then in March, when all
[20:32.810 --> 20:38.790]  the proof of concepts were also like, easy to run running and so on. Then I also started informing
[20:38.790 --> 20:44.710]  the other vendors who I found to have coexistence in their data sheets mentioned. So
[20:45.190 --> 20:50.450]  it's probably not everyone who uses it, but at least people I know that they use it.
[20:51.850 --> 20:56.610]  So this is something that like if other people were going to go look at other chipsets,
[20:56.610 --> 21:01.290]  the coexistence is what they'd be looking for, for a similar style of vulnerability.
[21:02.450 --> 21:06.650]  I'd be something else. So I'm not sure how it is with all the other devices,
[21:06.650 --> 21:12.270]  but it's definitely existing in a couple of devices and all proprietary.
[21:12.650 --> 21:18.290]  And that coexistence is controlled by that one. Was it CC10 chip?
[21:18.290 --> 21:23.250]  I forget the name of the chip. It was the microcode portion that...
[21:26.090 --> 21:28.330]  Ah, the D11, you mean?
[21:28.330 --> 21:29.770]  Yes, that's the D11.
[21:29.770 --> 21:35.090]  Yes, it's controlled by this low level stuff, because it must be real time. So it's an
[21:35.090 --> 21:39.630]  arbitration between the Bluetooth and the wireless, and the wireless needs to run this
[21:39.630 --> 21:44.810]  into the lowest part of the stack that is directly on this microcontroller.
[21:45.570 --> 21:49.410]  Could you... is there anything else about that microcontroller that you
[21:49.410 --> 21:52.470]  want to talk about or share with people that are watching right now?
[21:53.550 --> 21:58.850]  Well, I think that it's very interesting if you can have the ability to hack this,
[21:58.850 --> 22:06.410]  because it's the part that can decide what to transmit and whether the received frame should
[22:06.410 --> 22:11.850]  be pushed to the host. So it's very interesting because you can also develop a very small stack
[22:11.850 --> 22:19.150]  over there, and the behavior of this stack would be completely not detectable by the host. So there
[22:19.150 --> 22:25.210]  is no way for the host to understand what the U-code might do. So if you find a way for changing
[22:25.210 --> 22:29.310]  the U-code over the air, then wow, that's amazing what you can do.
[22:29.310 --> 22:34.310]  But so is this something that could like proactively drop packets with like a magic value
[22:34.310 --> 22:35.990]  or something like that?
[22:35.990 --> 22:40.650]  Yeah, yeah, yeah. For this test that we were doing with the coexistence, we were
[22:41.450 --> 22:47.850]  sending command to the wireless interface over the air, and the U-code is the D11 core is receiving
[22:47.850 --> 22:53.390]  them, then dropping them, and changing the configuration of the wireless interface.
[22:53.390 --> 22:56.050]  This is totally unnoticed by the host.
[22:58.970 --> 23:05.850]  That's awesome. What are the next areas that you guys are looking into for like future research?
[23:05.850 --> 23:09.030]  Do you have anything already lined up? Anything you can talk about?
[23:09.610 --> 23:16.170]  Probably the can talk about is the part, right? I mean, obviously like wireless security, but
[23:16.170 --> 23:22.810]  yeah. So there will be stuff coming up. So I will definitely do further research
[23:23.730 --> 23:28.010]  and I mean, Francesco has been doing this for so many years, probably nobody else is like
[23:28.010 --> 23:34.610]  questioning what he's going to do in the future when he has been doing it for the last 15 years.
[23:37.970 --> 23:43.670]  Fair enough. Yeah, I'm running out of questions. We do have a couple more people that are
[23:43.670 --> 23:50.690]  are typing now. Yeah. So I mean, we've got a few moments. Is there anything that you guys
[23:50.690 --> 23:53.970]  want to talk about proactively that we haven't already covered?
[23:55.610 --> 24:01.450]  I mean, so something that is kind of interesting is that like people currently like also if you
[24:01.450 --> 24:06.910]  look into the first YouTube comments of the talk, it's like they are like, you are just publishing
[24:06.910 --> 24:12.310]  this because I don't know there is this exposure notifications for Corona and stuff like this.
[24:12.310 --> 24:18.270]  But actually, we have been working on this, I mean, since much longer time than this. So it's
[24:18.270 --> 24:25.690]  nothing that's like connected to Corona or something in that sense. And also, I think like,
[24:25.690 --> 24:32.390]  for average people who just keep their system up to date and just use it. I don't think that it's
[24:32.390 --> 24:37.570]  like a big threat in that sense. I mean, of course, like if you go on DEF CON, where a lot
[24:37.570 --> 24:41.810]  of hackers are around you, you might want to disable Bluetooth and Wi Fi, but like disabling
[24:41.810 --> 24:51.390]  Wi Fi also has been a well known practice in the past. So yeah, it's in your experience,
[24:51.910 --> 24:56.570]  in your experience, does disabling like Bluetooth and Wi Fi in the device actually turn off the
[24:56.570 --> 25:04.250]  full radio? It doesn't turn off the chip, but it disables the host deck usually in a way
[25:04.250 --> 25:11.610]  that you cannot establish active connections anymore. It depends. But so yeah, I mean,
[25:11.610 --> 25:17.710]  of course, like switching off your device if you don't want it to be hacked is a good practice,
[25:17.710 --> 25:23.130]  probably even taking out the battery. It really depends. It really depends on your on your level
[25:23.130 --> 25:29.990]  of paranoia, of course. But so yeah, so those those people who who are afraid because they
[25:29.990 --> 25:34.010]  have like, I don't know if you if you have something on your smartphone that's like worth
[25:34.630 --> 25:40.590]  100,000 bucks or something, then maybe consider being hacked because this is like the range where
[25:40.590 --> 25:47.550]  exploits for those devices start, right? So yeah, so that's probably the threat model here.
[25:47.550 --> 25:53.330]  And I don't think that like, I mean, until someone writes that Bluetooth form, who knows?
[25:53.330 --> 26:00.110]  But I don't think that until then, like, Bluetooth would be the preferred way to hack people.
[26:00.310 --> 26:07.870]  What I still don't like about like, or how all this stuff like goes is that still Wi Fi and
[26:07.870 --> 26:13.670]  Bluetooth are like, I mean, they have been exploited back in 2017, very publicly, and they
[26:13.670 --> 26:19.130]  are still very insecure. And that's, that's the part here, like they have been insecure for years.
[26:19.130 --> 26:25.310]  And there's, I mean, some things are happening, but really vendors and so on, they really need
[26:25.310 --> 26:32.050]  like some motivation to fix stuff even further. And so I wouldn't really say like, we are making
[26:32.050 --> 26:37.670]  it more insecure. It's really like kicking them somewhere and saying like, please, please fix it,
[26:37.670 --> 26:43.970]  make it better. Like we have seen like at least some improvements within the Broadcom firmware,
[26:43.970 --> 26:48.410]  it's still not super secure, but it's secure after the things that happened in 2017. And
[26:48.950 --> 26:52.230]  yeah, so I hope to move it a bit more in this direction.
[26:52.310 --> 26:56.130]  Do you have a general feeling for like, if there's any particular chips that
[26:56.130 --> 27:00.390]  are seen more secure than others, like a better coding practices or
[27:00.870 --> 27:04.010]  anything like that? Or are they all kind of roughly the same?
[27:05.050 --> 27:09.970]  There are at least some that are more obscure than others. I mean, Qualcomm has their own
[27:09.970 --> 27:17.030]  hexagon DSP, which you can emulate, but there are, I think there's a disassembler plugin for
[27:17.030 --> 27:22.930]  Ghidra, which partially works. And then there is two for IDA, but they also don't support like
[27:22.930 --> 27:28.070]  all commands. Then you just have disassembler and not the compiler, Ghidra you would also have
[27:28.070 --> 27:34.250]  the compiler. So it's really bad quality of those tools for Qualcomm. And then still
[27:34.250 --> 27:39.650]  last year at DEF CON, there has been a talk about Qualcomm Wi-Fi having a bug. And they,
[27:39.650 --> 27:42.690]  so after the talk, I just went to them, I was like, how did you find it? I said,
[27:42.690 --> 27:50.290]  just like static reverse engineering. I was like the hexagon, right? But yeah, so
[27:51.530 --> 27:57.150]  not sure if Qualcomm is more obscure or really more secure, at least they have more people on
[27:57.150 --> 28:05.030]  security conferences and, but yeah, it's, it's hard to tell. So I think in general,
[28:05.030 --> 28:10.010]  if you have newer hardware, then you have more security measures in it and like newer chips.
[28:10.010 --> 28:17.610]  So if you buy like the most expensive Google or iPhone or whatever, it's probably more secure
[28:17.610 --> 28:23.490]  than if you buy some very cheap smartphone with cheap chips that didn't have so much money for
[28:23.490 --> 28:29.190]  development, but it's still no guarantee. So it just, it could have the budget to make it secure
[28:29.190 --> 28:36.570]  if they wanted to make it secure. It's no guarantee, right? Right. Fair. And the last
[28:36.570 --> 28:42.150]  question that I think that we can take, and this one's not directly about your presentation. Someone
[28:42.150 --> 28:46.970]  wants to know how you displayed your hand behind your presentation in the actual recorded video.
[28:48.210 --> 28:55.430]  So that's actually a method that I stole from Daniel Crusoe, the guy who did the spectra.
[28:55.490 --> 29:01.310]  So for his lectures, he's using OBS and he has a white wall. I mean, I also have the white wall
[29:01.310 --> 29:05.570]  behind me, right? And then I point with my hand and this is the part that I'm filming. And so
[29:05.570 --> 29:11.410]  this, this part would be like behind the slide and in the slide, I said white as an opaque color,
[29:11.410 --> 29:16.670]  and then I put my hand off. So behind it, so then I have the layers and I can do the
[29:16.670 --> 29:19.390]  the pointing. So this would be the pointing.
[29:20.010 --> 29:23.710]  Nice. I'm sure some other presenters will appreciate that touch.
[29:24.970 --> 29:29.650]  Okay. Well, that's all the time that we have for you. Thank you both for joining us for the Q&A
[29:29.650 --> 29:39.210]  session. Thank you both for getting content into the virtual DEF CON and yeah, have a nice day.
[29:40.270 --> 29:41.170]  Thank you, too.
[29:42.090 --> 29:42.670]  Take care.
[29:42.670 --> 29:43.390]  Thank you, too.
